Is this really deprecated per the guidelines? https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines/index.md#setting-deprecated I can't find authoritative text suggesting so.

If it is, then I guess we want an accompanying content PR?
I know @OnkarRuikar syncs experimental/deprecated/non-standard statuses between BCD and content. I believe that sync would mean that https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments/callee gets a deprecated header and https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments#properties would get an inline deprecated badge.

then I guess we want an accompanying content PR?

I suggest not to manually create a PR for this in mdn/content repo. There will be a sync PR for the BCD release, containing these changes.

The BCD - mdn/content synchronization is automated(at the moment going trough same phases as markdownlint automation did). We want to make mdn/browser-compat-data the single source of truth.

The latest specs (2023) still defines the property on arguments object:

8. Perform ! DefinePropertyOrThrow(obj, "callee", PropertyDescriptor { [[Get]]: %ThrowTypeError%, [[Set]]: %ThrowTypeError%, [[Enumerable]]: false, [[Configurable]]: false }).

@Elchi3 This is deprecated in the sense that it's forbidden in strict mode. Because ES can never unship APIs, this is closest to "removal from spec" in the ES world.

I'm not sure what content change is necessary, but (1) it's already listed on the deprecated features page (2) accessing callee throws the same error as func.caller, and the word "deprecated" is in the error description. caller is also described as deprecated.

In fact, I do have a content change prepared for the related pages, although it's not totally related to this deprecation, but more for the page types work. The BCD syncing is automatic as Onkar noted, so I think this is all we need.

@OnkarRuikar Your quoted spec is the "throwing" part, which is strictly more "deprecated-like" than not installing the property at all. callee's continued support lives in sloppy mode, which corresponds to the CreateMappedArgumentsObject section below.

I'm double checking here because In case of with, there was a debate and we talked to TC39 to add "discouraged" into the spec text officially. So that, to me, is an authoritative source to call with "deprecated" in our docs.

• Editorial: disambiguate with statement's status tc39/ecma262#2441
• javascript.statements.with - The feature is NOT deprecated #10490

It would be nice to have a similar authoritative spec text for this case so that the discouragement position is as strong as that for with.

accessing callee throws the same error as func.caller

Thanks! Even though it is not a non-standard feature I guess this could count as a signal for us to mark it in fact deprecated per this guideline rule:

For non-standard features, notice from implementing browsers (for example, a console deprecation warning) or vendor documentation

What do you think?

If I try hard enough, I can probably find meeting notes from ES5 about how implementers dislike this feature (which is why it's removed from strict mode at all). But sifting through pre-ES6 notes is always a pain, so if you are convinced, we should be good :) After all, developers not being able to use the feature is already a stronger signal than a mere editorial marker of deprecation.